Building the KiCad EDA Suite from Sources
Page created June 6th, 2023.
For electronic circuit board design, I use the KiCad EDA suite. This is a GPL-licensed free software application which began life at Cern many years ago and is now under continued (and I must say, quite aggressive) development by the for-profit KiCad Services Corporation and volunteers around the world. I think this software is a perfect example of how free software and commercial interests can benefit one another and from each other.
I decided to install the latest KiCad EDA release, which at this writing (June 2023) is version 7.0.5, by building from sources. The target machine is running a recent install of Debian GNU/Linux 11.7, code-named Bullseye, for the x86_64 architecture. In fact, I just installed this operating system yesterday, since my other Debian installation, 10.x, code-named Buster, is using older versions of various software that I have wanted to update for quite some time now.
For this endeavor, I found the page How to build KiCad on Linux (the easy way) quite helpful. As the page points out, the trickiest part is making sure that the needed tools and dependencies are installed. At this writing, the page suggests the following for Debian Bookworm (currently a preview of what will eventually be the next major release of Debian GNU/Linux, version 12.x):
$ apt build-dep kicad
and
$ apt install unixodbc-dev
That build-dep command in particular is very cool: It does what its name suggests, which is to install the dependencies needed to build a package, rather than to install the package itself. This comes with a minor caveat, though: It installs the dependencies that are listed for the version of the package that it knows about. So, for example, if its kicad package installs, say, KiCad 6.x, and if we want to build KiCad 7.x, and if new dependencies have been added between those major releases, then build-dep will not know about the new dependencies and, it follows logically, will not install those.
Although the above suggestions were meant for Bookworm, they seemed to work correctly on Bullseye as well, with the above caveat, which we'll see momentarily...
Note: I don't know whether the above would install compiler tools like GCC and other tools needed for the build like CMake, because I already installed those kinds of development tools prior to starting this process. Among those, I installed the tools needed to provide a functional build environment for NuttX, using the notes I helpfully collected for myself, as well as for my worldwide readership, in Adventures with NuttX.
Somewhere in this process, I fetched the KiCad source code directly from its GitLab repository and switched to the 7.0.5 tag, which is the newest release at this writing, created the build directory, and entered it:
$ git clone https://gitlab.com/kicad/code/kicad.git
$ cd kicad
$ git checkout 7.0.5
$ mkdir build
$ cd build
I continued to follow the easy build instructions for KiCad, using cmake-gui for convenience. But as soon as I clicked the CMake GUI's "Configure" button, I ran into the first problem: My installed version of CMake, which in fact is the default one installed with sudo apt install cmake, was not new enough. This is something that comes up occasionally with Debian. On the one hand, the distribution is very stable, which provides a reliable experience. That's one of the big reasons I prefer Debian over other distributions. On the other hand, that stability comes at the cost of some lag between software releases and their appearance in the default Debian package repository. But the good news is that there is a workaround that allows one to install newer packages than those that are normally available for a given version of Debian: the "backports" repository.
I added the following lines to /etc/apt/sources.list:
# Added by high12noon on 2023-06-06 for newer versions of packages:
#
# According to https://backports.debian.org/Instructions/ the normal
# (non-backports) package will install by default. To install from
# backports, use:
#
# apt install <package>/bullseye-backports
# or
# apt install -t bullseye-backports <package>
deb http://deb.debian.org/debian bullseye-backports main
deb-src http://deb.debian.org/debian bullseye-backports main
Now, that by itself does not cause the newer programs to be installed; since packages from backports have duplicate names to those in the normal package repository, they are automatically given a lower priority. This means that the default (read: older) package will install unless we instruct apt otherwise.
Whenever we edit the list of package repositories, we have to tell apt to update its databases:
$ sudo apt update
Once that was done, I first removed the cmake and cmake-gui that were already installed:
$ sudo apt remove cmake cmake-gui
Then I installed cmake and cmake-gui from the backports repository as follows:
$ sudo apt install -t bullseye-backports cmake cmake-gui
I don't know whether it was actually necessary to remove the already-installed ones. Perhaps apt would be smart enough to update those packages. But I felt it was safer to do it this way.
With a new enough CMake installed, I once again brought up cmake-gui and clicked the "Configure" button. This time, it complained that harfbuzz was not found. It seems that apt build-dep kicad didn't install the harfbuzz-dev package. Perhaps this is a newer dependency in KiCad 7? I installed it with:
$ sudo apt install libharfbuzz-dev
and clicked "Configure" again. This time it worked, and I was able to move on to generating the Makefile by clicking "Generate."
From there, it was smooth sailing, except that it took a long time. Several hours, in fact. I navigated to the build directory where cmake-gui generated the Makefile and ran make. Several hours later, the build completed, and I was able to run sudo make install and run KiCad. Although the first build did take a long time, I think that if I ever decide to hack on KiCad or perhaps update to a newer release by switching the clone to a different tag or branch, a rebuild will probably take substantially less time, since it probably wouldn't be necessary to compile every single file.
As mentioned in How to build KiCad on Linux (the easy way), I had to run ldconfig to update the library caches, or else the PCB editor couldn't find needed libraries and therefore couldn't run.
And that's that! Now the real work begins, to make some circuit board designs...
Send feedback to: the name of this blog at mail dot com.